A file server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially-formatted file in which information about other files and directories are stored. A filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
A common type of file system is a “write in-place” file system, an example of which is the conventional Berkeley fast file system. In a write in-place file system, the is locations of the data structures, such as inodes and data blocks, on disk are typically fixed. An inode is a data structure used to store information, such as meta data, about a file, whereas the data blocks are structures used to store the actual data for the file. The information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file. The references to the locations of the file data are provided by pointers, which may further reference indirect blocks that, in turn, reference the data blocks, depending upon the quantity of data in the file. Changes to the inodes and data blocks are made “in-place” in accordance with the write in-place file system. If an update to a file extends the quantity of data for the file, an additional data block is allocated and the appropriate inode is updated to reference that data block.
Another type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block on disk is retrieved (read) from disk into memory and “dirtied” with new data, the data block is stored (written) to a new location on disk to thereby optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. A particular example of a write-anywhere file system that is configured to operate on a filer is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc. of Sunnyvale, Calif. The WAFL file system is implemented within a microkernel as part of the overall protocol stack of the filer and associated disk storage. This microkernel is supplied as part of Network Appliance's Data ONTAP™ storage operating system, residing on the filer, that processes file-service requests from network-attached clients.
As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a storage system that manages data access and may, in case of a filer, implement file system semantics, such as the Data ONTAP™ storage operating system, which is implemented as a microkernel. The Data ONTAP storage operating system is available from Network Appliance, Inc., of Sunnyvale, Calif., and is implements a Write Anywhere File Layout (WAFL™) file system. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
Disk storage is typically implemented as one or more storage “volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate storing of parity information with respect to the striped data. In the example of a WAFL file system, a RAID 4 level implementation is advantageously employed. This implementation specifically entails the striping of data across a group of disks, and separate parity storing within a selected disk of the RAID group. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity) partitions in a single disk arranged according to a RAID 4, or equivalent high-reliability, implementation.
The Microsoft Windows family of operating systems, including Microsoft Windows NT and Microsoft Windows 2000, utilize the NT file system (NTFS). Files stored within a NTFS file system may utilize multiple data streams. The representation of such NTFS streams on a file server is described in the above-incorporated patent application, entitled SYSTEM AND METHOD FOR REPRESENTING NAMED DATA STREAMS WITHIN AN ON-DISK STRUCTURE OF A FILE SYSTEM.
An example of the use of multiple data streams may involve the creation of a document, having summary, main content and index sections, by word processor software, e.g., Microsoft Word, executing on the conventional Microsoft Windows NT operating system. By employing the multiple data streams feature of the NT file system (NTFS), the summary section may be stored at a location on disk that is separate from the main content and index sections of the document. This enables a user (e.g., a client) to retrieve just the summary section independent of those other sections of the document. Note that apportionment of the various sections (named data streams) associated with the document is arbitrary and user selectable, and that named data streams may be created for both files and directories (folders).
In an exemplary file system, each unit of information associated with a file, including, for example, its name, its owner, time stamps, etc is implemented as a file attribute. Both files and directories have attributes, wherein each attribute may consist of a single data stream. Such an implementation facilitates the addition of new attributes to a file, including data content attributes. Therefore, files and directories may contain multiple data streams, however, each on-disk file must contain at least a default data stream through which the file data is accessed.
In the exemplary WAFL file system, individual files are described by inodes, including, for example, directory inodes, regular inodes and stream inodes. A stream inode represents a named data stream so that multiple data streams may be stored on disks associated with a storage appliance as representations embodying the stream inode type associated with a file. Each stream inode has its own size, file share locks, byte range locks and data blocks; however other file attributes, such as time stamps, group and user ownership information, and access control lists are common for all named data streams and are stored in an on-disk “base inode”. The default data stream, along with its size, data blocks, file share locks and byte range locks, is also stored in the base inode. Additionally, the names and file handles of the data streams are stored in a “hidden” directory within the file system that is referenced by the base inode. The hidden directory is represented as a stream_dir inode type. The hidden directory is “invisible” in a directory hierarchy that is viewed by a user (e.g., a client) external to the file system and, thus, is inaccessible through an external file system protocol, such as the Common Internet File System protocol.
In the example of the Write Anywhere File Layout (WAFL) file system, by Network Appliance, Inc., of Sunnyvale, Calif., a file is represented as an inode data structure adapted for storage on disks. Broadly stated, the on-disk format representation of the exemplary WAFL file system is block based using, e.g., 4 kilobyte (KB) blocks and using inodes to describe the files. An inode is a data structure used to store information, such as meta data, about the file. That is, the information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, or other attributes, described further below. The WAFL file system uses a file handle, i.e., an identifier that includes an inode number, to retrieve an inode from disk. The exemplary WAFL file system also uses files to store meta data describing the layout of its file system. These meta data files include, among others, an inode file. The on-disk format structure of the WAFL file system, including inodes and the inode file, is disclosed and described in U.S. Pat. No. 5,819,292, entitled METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM, by David Hitz, et al., issued on Oct. 6, 1998 and incorporated by reference as though fully set forth herein.
A file is represented in the exemplary WAFL file system as an inode data structure adapted for storage on disk. FIG. 1 is a schematic block diagram illustrating the on-disk inode 100, which preferably includes a meta-data section 110 and a data section 150. The information stored in the meta-data section 110 of each inode 100 describes the file and, as such, includes the type (e.g., regular or directory) 112 of file, the size 114 of the file, time stamps (e.g., access and/or modification) 116 for the file and ownership, i.e., user identifier (UID 118) and group ID (GID 120), of the file. The meta-data section 110 further includes a xinode field 130 containing a pointer 132 that references another on-disk inode structure containing, e.g., access control list (ACL) information associated with the file or directory. The contents of the data section 150 of each inode, however, may be interpreted differently depending upon the type of file (inode) defined within the type field 112. For example, the data section 150 of a directory inode contains meta-data controlled by the file system, whereas the data section of a regular inode contains user-defined data. In this latter case, the data section 150 includes a representation of the data associated with the file.
Specifically, the data section 150 of a regular on-disk inode may include user data or pointers, the latter referencing 4 KB data blocks on disk used to store the user data. Each pointer is preferably a logical volume block number to thereby facilitate efficiency among the file system when accessing the data on disks. Given the restricted size (128 bytes) of the inode, user data having a size that is less than or equal to 64 bytes is represented, in its entirety, within the data section of that inode. However, if the user data is greater than 64 bytes but less than or equal to 64 kilobytes (KB), then the data section of the inode comprises up to 16 pointers, each of which references a 4 KB block of data on the disk. Moreover, if the size of the data is greater than 64 kilobytes but less than or equal to 64 megabytes (MB), then each pointer in the data section 150 of the inode references an indirect inode that contains 1024 pointers, each of which references a 4 KB data block on disk. In addition, the size field 114 of the meta-data section 110 of the inode refers to the size of the file.
Some known storage operating systems contain the capability to generate a snapshot of the file system. In the example of a WAFL-based file system, snapshots are described in TR3002 File System Design for a NFS File Server Appliance by David Hitz et al., published by Network Appliance, Inc. and in U.S. Pat. No. 5,819,292 ENTITLED METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM, by David Hitz et al., which are hereby incorporated by reference.
“Snapshot” is a trademark of Network Appliance, Inc. It is used for purposes of this patent to designate a persistent consistency point (CP) image. A persistent consistency point image (PCPI) is a point-in-time representation of the filer, and more particularly, of the active file system, stored on a storage device (e.g., on disk) or in other persistent memory and having a name or other identifier that distinguishes it from other PCPIs is taken at other points in time. A PCPI can also include other information (meta data) about the active file system at the particular point in time for which the image is taken. The terms “PCPI” and “snapshot” shall be used interchangeably through out this patent without derogation of Network Appliance's trademark rights. Generally, a snapshot may be viewed as an example of a read only reference store. In contrast, the active file system may be viewed as an example of an active store that permits read and write operations.
A snapshot is a restorable version of a file system created at a predetermined point in time. Snapshots are generally created on some regular schedule. The snapshot is stored on-disk along with the active file system, and is called into the buffer cache of the filer memory as requested by the storage operating system. An exemplary file system inode structure 200 is shown in FIG. 2. The inode for an inode file 205 contains information describing the inode file associated with a given file system. In this exemplary file system inode structure the inode for the inode file 205 contains a pointer to an inode file indirect block 210. The inode file indirect block 210 contains a set of pointers to inodes 217, which in turn contain pointers to indirect blocks 219. The indirect blocks 219 include pointers to file data blocks 220A, 220B and 220C. Each of the file data blocks 220(A-C) is capable of storing, in the illustrative embodiment, 4 kilobytes (KB) of data.
When the storage operating system generates a snapshot of a given file system, a snapshot inode is generated as shown in FIG. 3. The snapshot inode 305 is, in essence, a duplicate copy of the inode for the inode file 205 of the file system 200. Thus, the exemplary file system structure 200 includes the inode file indirect blocks 210, inodes 217, indirect blocks 219 and file data blocks 220A-C as in FIG. 2. When a user modifies a file data block, the file system layer writes the new data block to disk and changes the active file system to point to the newly created block.
FIG. 4 shows an exemplary inode file system structure 400 after a file data block has been modified. In this illustrative example, file data block 220C was modified to file data block 220C′. When file data block 220C is modified to file data block 220C′, the contents of the modified file data block are written to a new location on disk as a function of the exemplary WAFL file system. Because of this new location, the indirect block 419 must be rewritten. Due to this changed indirect block 419, the inode 417 must be rewritten. Similarly, the inode file indirect block 410 and the inode for the inode file 405 must be rewritten. Thus, after a file data block has been modified the snapshot inode 305 contains a point to the original inode file indirect block 210 which in turn contains pointers through the inode 217 and an indirect block 219 to the original file data blocks 220A, 220B and 220C. However, the newly written indirect block 419 includes pointers to unmodified file data blocks 220A and 220B. The indirect block 419 also contains a pointer to the modified file data block 220C′ representing the new arrangement of the active file system. A new inode for the inode file 405 is established representing the new structure 400. Note that meta data (not shown) stored in any snapshotted blocks (e.g., 305, 210, and 220C) protects these blocks from being recycled or overwritten until they are released from all snapshots. Thus, while the active file system inode for the inode file 405 points to new blocks 220A, 220B and 220C′, the old blocks 210, 217, 219 and 220C are retained until the snapshot is fully released.
After a snapshot has been created and file data blocks modified, the file storage operating system can reconstruct or “restore” the file system inode structure as it existed at the time of the snapshot by accessing the snapshot inode. By following the pointers contained in the snapshot inode 305 through the inode file indirect block 210, inode 217 and indirect block 219 to the unmodified file data blocks 220A-C, the storage operating system can reconstruct the file system as it existed at the time of creation of the snapshot.
In known restoration techniques from snapshots, the snapshotted files are copied from the snapshot to the active file system. These copies are generated by duplicating inodes and data blocks stored in the snapshot and writing these duplicated blocks and inodes to the active file system. Thus, the snapshot is effectively duplicated into the active file system. A noted disadvantage of such a restore technique is that each inode or data block of the snapshot needs to be copied. Such copying, in the case of a large file system, can require a substantial amount of time and processing power. For example, files may be sized on the order of tens of gigabytes. Similarly, using known file restore techniques from a snapshot, the volume containing the snapshotted file must be large enough to accommodate two full copies of the file, namely, the snapshot and the file in the active file system. In the example of the large file, a volume may not be of sufficient size to accommodate two full copies of the file.
One technique to avoid resource-consuming duplication the entire file system is to use the storage operating system's capabilities to restore on demand. Restore on demand techniques are described generally in U.S. patent application Ser. No. 10/101,901 entitled SYSTEM AND METHOD FOR MANAGING A PLURALITY OF SNAPSHOTS by Hugo Patterson et al., now issued as U.S. Pat. No. 7,475,098 on Jan. 6, 2009. A noted disadvantage of such restore on demand technique is an entire directory tree associated with the file must also be restored. For example, if the desired file to be restored is two directories down, for example, in /foo/bar/file, then the directory /foo and the subdirectory /bar must also be restored. This reduces the efficiency of the file restoration process. Additionally, such restore on demand techniques typically cannot support the restoration of files that include streams or other metadata that are not stored internal to the file, but are stored in a separate data stream associated with the file. Such restore on demand techniques typically utilize the snapshot copying methodology, described above, to restore a particular file. Thus, the noted disadvantages of the snapshot duplication method, e.g., processing overhead and use of file system space, are inherent in these restore on demand techniques.
However, there are instances when the restoration of only a single file from a snapshot, without restoring the associated directory tree, is desired. For example, the entire file system may not suffer an error condition, but a single file may have become corrupted or otherwise needs to be restored. Conventional restore on demand techniques may not properly restore those files that include one or more data streams, as the data streams are not contained within the data section of the file. These streams and associated metadata may be restored by, for example, restoring an entire volume from a snapshot; however, the restoration of an entire volume is a clearly inefficient approach when only a single file in a large file system needs to be restored. Thus, it is desirous for a system and method to restore a single file from a snapshot that includes one or more data streams associated therewith.